WK3 Decision Support Systems for Business Intelligence CH7

7

DESIGNING A DECISION

SUPPORT SYSTEM

At this point, you may be sold on the idea of decision support systems. You believe

they are important, and you want to include them within the assets of your department

or organization. The next logical question is how to start. The answer is a clear and

unequivocal, "it depends."

The best approach depends upon the kind of systems already in place and the intended

focus of the DSS. As with any good systems analysis and design process, it is important to

understand the needs of the application and to select the

models,

model management system,

databases, database management system, and user interface in a manner that

best

meets the

needs of that application. Successful DSS can be built on almost any kind of platform with

almost any kind of software, but it is crucial that the choices fit the application. Selecting

tools and vendors before understanding the problem or forcing tools to meet needs after

the fact will certainly lead to failure.

The physical design of a successful DSS must follow a logical design, which in turn

must be guided by the decision-making process. In particular, designers should ask the

same fundamental questions as those on which reporters rely:

•

Who

needs the DSS?

•

What

advantages does the user expect by using the DSS?

•

When

will the DSS be used?

•

Where

does this system fit into the general business process?

•

Why

is a DSS needed?

•

How

will the DSS be used?

Decision Support Systems for Business Intelligence

by Vicki L. Sauter

315

316

DESIGNING A DECISION SUPPORT SYSTEM

While these questions seem obvious, we must keep returning to them as a reality test that

the system is providing support for decisions.

Unfortunately, the systems development life cycle approach, which provides a reliable

framework in which to design transaction processing systems (TPS), generally does not

work for DSS design. Unlike TPS, DSS typically will have fuzzy or even wicked problem

definitions that change substantially over time. In addition, since DSS support decision

making, generally that of higher level managers, its design is highly subjective and subject

to change. Since such managers have less time and less inclination to attend training

sessions, it is necessary to create a system that has lower training needs than those generally

associated with TPS. Finally, it is difficult to determine with certainty that a DSS works

properly for all applications. Test data sets and problem scenarios can be developed for TPS

and run against a system to determine whether it works properly. But, by its very nature,

which is to be flexible and allow decision makers to use it as it best fits their decision style,

DSS cannot be "tested" to ensure that they always work properly.

Therefore, DSS require a different approach to design. It must be a process and a

product that relate to the constraints of the domain in which the DSS will be used. Gachet

and Sprague (2005) remind us that there must be tangible improvements in the life of

the decision maker to justify using the system. The DSS must make it easier to get data,

improved knowledge management, and improved outcomes for it to be used. The faster the

DSS can make the points of the value, the faster the DSS will be adopted. If those factors

are to be realized, they argue, designers must use a context-based development life cycle

for DSS design. This methodology emphasizes the following:

1.

Identify Requirement Specifications Based on Contextual Issues.

This means that

the first step to design is to identify the user interface requirements from the end

users.

In ad-

dition, at this stage designers must identify needs for data integration to bring improvement

in the process and where there is a need for parity with workflow.

2.

Preliminary Conceptual Design.

There must be an emphasis on inputs and outputs

from the end-user requirements: what do they need and how must it be represented. Also

in this step designers identify specific hardware and software requirements and identify

specifications for databases.

3.

Logical Design and Architectural Specifications.

In this stage, designers begin

to specify user interfaces. Using early prototyping, they can compare their understanding

of the interface needs with the users to ensure they understood the message correctly. In

addition, designers must specify the procedures for obtaining data and sharing it with others

and the distributed architecture required for appropriate levels of integration of the DSS

with other systems. Finally, designers must model data and the strategic design as well as

develop procedures for maintenance and backup of the system.

Design insights

Picking a Team

As in any large-scale, important application, the question of

who

should do the development may

be critical. Often project teams are hand-picked members of the staff who are pulled together

especially for their ability to respond to a particular need. They are thought of as a SWAT team

in that they develop the DSS and then return to their separate departments, If they are successful,

then they are often called upon for the next important application, Especially with the design of

DSS,

here are sometimes subtle elements of group synergy that lead to success for the group in

one application but not in other applications. Unfortunately, the understanding of what leads to

such success in high-performance projects is not well understood.

DESIGNING A DECISION SUPPORT SYSTEM

4.

Detailed Design and

Testing.

While testing is important in any design process, in

this methodology, the emphasis is on testing the system with the end users and testing the

integration of the system with the decision makers' functions. That means we need to test

if individual decision makers can use the system and if it flows nicely in their workflow

process. Of

course,

this also includes testing the resilience, reliability, and scalability of the

system and its performance under specific failure scenarios.

5.

Operational Implementation.

In this stage, the system is made operational in a

subset of the decision makers' world. Systems are linked to appropriate parts of the data

warehouse and than are made available to used by decision. Those decision makers involved

in the test would be trained and receive access to the system.

6.

Evaluation and

Modification.

Finally, the system is evaluated in terms of it overall

user acceptance, system integration, architecture resilience, and scalability. Finally the

system is modified across the organization.

7.

Operational

Deployment.

Final changes are made in the system and it is distributed

to all users after training. This stage includes continuous monitoring of both technical

problems in the operation of the DSS and patterns of use that might suggest problems.

Pick (2008) further addresses the process of Gachet and Sprague's first step of require-

ments definition. He states that it is important to elucidate the

value

of the DSS before

beginning to build the system. Pick's argument is that the benefits of a DSS are often

much more subtle than decision makers expect, and so it is important to sensitize them to

the benefits that might be expected as the process starts. In addition, consideration of the

benefits early in the process will help decision makers develop a better understanding of

the opportunities that might be built into the system. He suggests questions such as the

following (Pick, 2008, p. 725):

• If we will be better able to cope with large or complex problems, how much may

that ability be worth?

• If the system will allow greater exploration and discovery, how much might the

resulting insights be worth?

• If there is better knowledge processing, how is this beneficial? If the system pro-

vides better understanding of a problem, can anyone judge the costs of incomplete

understanding?

So,

how would a designer know when he or she has a good DSS? Arnott and Dodson

(2008) provide a simple model of what impacts DSS success, as shown in Figure 7.1.

They bring two basic concepts to a methodology for designing DSS. First they, as Gachet

and Sprague (2006) and Pick (2008) say, the system must be comfortable for the user

and

improve decision making. Arnott and Dodson represent these concepts with "user

satisfaction" and "impact of the system." Notice that they show user satisfaction impacting

use.

What this implies is that if the users do not see the benefit of the system, find it too

difficult

to

use,

or

do

not

find

the information and models they perceive they need

to

complete

their decision, they are likely not to use the system at all. Clearly, even if the system

could

have a significant impact if it were used, it will not be a success if users do not find what they

need.

Arnott and Dodson (2008) also identify 10 critical success factors that need to be

satisfied to ensure both use and success (pp. 770-771):

• There is a committed and informed executive sponsor.

• There is widespread management support.

318

DESIGNING A DECISION SUPPORT SYSTEM

Figure 7.1. A model of

DSS

success.

(Adapted from D. Arnott, and G. Dodson, "Decision Support

Systems Failure," in F. Burstein and C.W. Holsapple (Eds.),

Handbook on

Decision

Support

Systems,

Vol.

I, Berlin: Springer-Verlag, 2008, p. 768.) Image is reprinted here with permission.

• The design team has appropriate skills.

• The design team uses appropriate technology.

• The design team has adequate resources.

• There is effective data management.

• There is a clear link with business objectives.

• There exists well-defined requirements.

• The system is allowed to evolve in development.

• The design team manages project scope.

These critical success factors mirror those generally accepted for system design. In par-

ticular, they highlight that the success of the DSS is dependent upon it being aligned with

business objectives and the technology plan of the organization. This will be discussed in

the next section.

These methodologies, however, identify decision makers being comfortable with the

system as the

critical

component to DSS success. It has been said that most users would

rather live with a problem they cannot solve than use a solution they cannot understand.

Thus making the DSS too "black box" or difficult to use will make it an instant failure.

Of course, designers need to know what factors will make the system easy to use and

comfortable to use. Norman (2007, p. 93) identifies six design rules:

Provide rich, complete and natural signals.

Be predictable.

Provide good conceptual models.

Make output understandable.

Provide continual awareness without annoyance.

Exploit natural mappings.

PLANNING FOR DECISION SUPPORT SYSTEMS

319

You will notice that this list tells us that understandability and requiring the system design

to follow the decision process are important aspects of good design. If the system is

predictable, cues (that guide the operations of the system or the evaluation of information)

are informative, and the output is presented in a clear and useful manner, the decision maker

is likely to use the DSS. Norman's emphasis is on providing a comfortable metaphor for

the system to which the user can relate. If the metaphor is right, then the procedures will be

understandable and the signals will be informative. In addition, he says that there should

be ubiquitous, yet nonobtrusive help available to the user.

Norman further emphasized rules of good design from the perspective of the system

that mirrors the themes of understandability and congruence with the decision process:

• Keep things simple.

• Give people a conceptual model.

• Give reasons.

• Make people think they are in control.

• Continually reassure.

• Never label human behavior as "error."

As a field, we tend to forget the most important design rule—keep everything simple. This

means the user interface, the processes needed to use the system, and the output. Removing

clutter and the newest but unnecessary gadget will encourage users to focus on the important

forms of support the system has to offer. In addition, these principles remind us that the

decision maker, not the DSS, ultimately will make the choice among alternatives. The

system must provide

support

and work in the way the user needs

or the decision maker will

not use the system.

Helping to make the system more predictable and more like a trusted

assistant will encourage decision makers to utilize its power. This includes the specific

attributes of the data, models, and user interface discussed in previous chapters.

PLANNING FOR DECISION SUPPORT SYSTEMS

In an ideal world, a multilevel plan guides the development of new DSS, such as that

described in Figure 7.2. The plan provides specifications for a specific DSS, in terms of the

way it interacts with the rest of the business processes, the kind of information that it will

provide, and its relative importance to the growth of the organization.

The specifications for DSS begin with the corporate strategic or long-range plan. A

strategic plan defines where the corporation expects to change its products or processes and

during what time line and provides direction to management of the corporation as a whole.

The

MIS

master

plan,

in

turn,

inherits its priorities and concerns from

this

corporate strategic

plan. The information system (IS) plan provides guidelines for prioritizing requests for

maintenance of existing systems and creation of new systems. In particular, it describes the

priorities for hardware, software, and staff necessary to respond to corporate strategy plans.

The IS master plan specifies modifications and maintenance of legacy systems, creation

and implementation of

new

systems, and diffusion of technology within the organization. It

should provide a plan for regular updating and other maintenance. Finally, it should provide

specifications for how staff should proceed in the creation of systems.

The DSS plan derives its priorities from the IS plan. Its goal is to coordinate future

implementations in the broadest possible way to ensure that all decision making is supported

320

DESIGNING A DECISION SUPPORT SYSTEM

Figure 7.2. Ideal planning.

in an appropriate way while planning for the reuse of code, flexibility for the future, and

the greatest potential for growth. In particular, the DSS plan should help answer questions

such as those posed by Sprague and Carlson (1982):

• How can current needs susceptible to DSS be recognized?

• How can the likely extent of their growth be assessed?

• What types of DSS are required to support the needs, now and in the future?

• What are the minimum startup capabilities required, both organizational and tech-

nical?

• What kind of plan can be developed to establish the long-term direction yet respond

to unanticipated developments in managerial needs and technical capabilities?

The DSS master plan would provide direction in the selection of hardware and software and

for integration with current systems. In addition, it could include a process for the creation

of reusable libraries of code that future designers could embed into similarly operating

DSS.

Designing a Specific DSS

Where DSS master plans exist, there is already some guidance in how to proceed. More

often than not, however, such plans do not exist. Then, designers must judge for themselves

how the DSS will fit into corporate plans and how it will interact with other systems. The

methodology described in Figure 7.3 will help designers ensure they get the best fit. Note

PLANNING FOR DECISION SUPPORT SYSTEMS

321

Goals:

Goncerns:

Initial analysis

• Identify key decisions

• Identify key information needs

• Theoretical or conceptual needs

• Industry-based needs

• Corporation-based needs

• Decision-specific parameters

Situation analysis

Goals:

· Understand the organizational setting

• Understand the task

• Understand the user characteristics

System design

Goals:

· Logical design

• System construction

• System evaluation

Goals:

Implementation

• Demonstration

• Training

• Deployment

Figure 7.3. DSS design methodology.

that it differs from the traditional systems development life cycle (SDLC) approach in that

it puts much more emphasis on determining what information needs to be provided and in

what fashion.

In the first stage, the designer learns the decision needs and environment. Designers

must know the key decisions under consideration by the decision maker and the related

information needs if the DSS is to be a tool that supports decisions. Then the designer can

begin to examine the parameters needed for consideration. Sometimes these parameters

will be easy to identify. For example, one key issue for investment executives is what

investments will provide the best returns. Knowing that, they need to consider return,

relative risk, tax advantages, term of

return,

and other fiscal parameters. On the other hand,

a chief executive officer-s key issue might be how to prevent a leveraged buyout or how

to strategically acquire a new vertical market. In this situation, even knowledge of the key

decision reveals information needs well.

DESIGNING A DECISION SUPPORT SYSTEM

Interviewing Techniques.

Often designers learn decision makers' needs by inter-

viewing them. There are many ways of conducting interviews, each of which provides

different kinds of information. For example, consider the interviewing styles noted in Fig-

ure 7.4 and discussed below. Interviews can be structured, unstructured, or focused. They

can follow case studies or protocol analysis. Finally, they can utilize tools such as card

sorting and multidimensional scaling.

The benefit of interviews is that they provide access to information or a perspective

on information that only the decision maker can provide. In both the structured interview

and the focused interview, the designer is interacting with the decision maker to obtain

information regarding a prescribed set of

topics.

This interaction might be in a face-to-face

setting, over the telephone, via computer, or by a pen-and-paper questionnaire. Generally

the richest information can be gleaned in a face-to-face setting in a neutral location (away

from the interruptions of the decision maker's normal activities). Good results can be

achieved with intelligent computer questionnaires (that move through the questions as a

function of the answers already provided); unfortunately, it is generally too expensive to

develop this software for a one-time use.

The degree of structure we build into the interview depends upon the specificity of the

information we seek. A structured interview is one in which the questions and the order in

which they will be asked are prescribed. The interviewer seeks short answers that provide

specific information. A focused interview, on the other hand, is relatively unstructured. In

this case, the interviewer also has a set of questions and an order for asking the questions.

However, the questions are more general, allowing the respondent to drive the direction

of the discussion. The interviewer must be prepared with probing questions that help the

respondent to focus on salient points.

Concepts

Problems

(major tasks

completed by

decision maker)

Solutions

(possible

outcomes)

Problem-

solving

steps

Raw concepts

Concept definition

Concept structures

Problems

Problem types

Solutions

Solution types

General steps

Specific steps

Structured

interviews

V

S

Focused

interviews

^

S

Case study

interviews

^

S

Protocol

analysis

^

V

S

V

Card

sorting

V

S

Multidimensional

scaling

s

S

s

Figure 7.4. Interviewing techniques matrix.

PLANNING FOR DECISION SUPPORT SYSTEMS

323

The more structured the interview, the greater the chance that the decision maker

will provide precisely the information sought. However, the more structured the interview,

the less likely the decision maker will provide insights the designer had not considered

previously. Therefore, if the designer is relatively uninformed about the choice process or

the decision maker's tendencies, the focused interview will allow for greater probing of new

avenues and hence greater understanding of the relationships between tasks and concepts

and why the procedures are sequenced in a particular fashion.

A protocol analysis is a different kind of interview because the interviewer does not set

even

the

basis of the discussion. Instead, respondents complete their typical choice processes

(including seeking information, generating alternatives, merging information, modeling,

sensitivity analysis, and other tasks included in the process). In order to communicate what

is happening and why it is happening, the decision maker verbalizes each task and subtask

and how a decision is made to move to another task. Usually, the interviewer does not

intervene but just records the descriptions provided. Protocol analysis is a valuable tool

because it helps the designer understand what the decision makers actually do in the choice

process, not what they

perceive

they do. This can be important because often the decision

maker is not aware of the actual tasks and hence cannot communicate them; this can be a

particular problem with very experienced decision makers, as discussed in Chapter 2.

Other Techniques.

Both the card-sorting technique and multidimensional scaling

require

the

decision maker

to

perform some task from which the designer infers the preferred

information and models. "Card sorting" refers to any task (whether or not one actually uses

cards,

even if one uses a computer simulation, such as that shown in Figure 7.5) in which

the decision maker iteratively sorts and combines things or concepts to determine a point

of

view.

For example, if the choice situation involves loan applications, the decision maker

Figure 7.5. Card Sorts simulation.

DESIGNING A DECISION SUPPORT SYSTEM

would sort a set of loan applications into multiple piles (perhaps "acceptable," "borderline",

and "unacceptable"). After the decision maker is comfortable with the similarity of the loan

applications in each

pile,

the designer analyzes the applications, with the help of the decision

maker, to determine the bases for the sorting. In other words, by noting the similarity and

differences among the applications within piles and between piles, the designer can glean

the set of criteria and standards for applying them. This helps the designer to understand

how to provide information and models for the decision maker.

Multidimensional scaling is a similar process in which decision makers are asked

to

rate

items as being similar or dissimilar. It differs from card sorting in that it forces the decision

maker to make choices among less complex alternatives. For example, rather than asking

whether or not an entire application is acceptable, the designer would ask the decision

maker to compare two candidates with particular incomes or particular debt ratios with

regard to their risks as loan candidates. Designers pose a large number of combinations and

analyze the data mathematically to determine the criteria being employed by the decision

makers. Unfortunately, the factors driving the decision often are not obvious or they lack

face validity. Hence the exercise can result in no useful information.

To identify more information needs, designers research the specific kind of decision

under consideration. For example, they can identify some informational needs by studying

the conceptual and theoretical bases for decisions, such as those covered in business school

classes. From such an analysis, designers could identify that investment executives need

to consider term of investment, relative risk, tax advantages, and other fiscal parameters in

addition to the fundamental question of return on investment. This would provide a starting

point for identifying additional needs. Alternatively, designers can gain insight by learning

about the industry in general. For example, designers of a DSS for a pharmaceutical firm

could gain insights by examining the creation, approval, marketing, and selling processes

for drugs. Issues such as testing, purity, reliability, and statistical confidence levels would

become evident. Such topics would likely have a home in any DSS in such a firm. Finally,

designers could examine copies of reports, memos, transactions, and models to identify

additional needs. This is comparable to an archeological analysis of

the

context from which

inferences about needs can be drawn.

Influence Diagrams.

It is important to be sure that all of the critical factors are

represented in a DSS. Hence, designers often rely upon tools like influence diagrams to

help them keep track of the range of information that is needed in a DSS. This popular

decision analysis tool helps to identify and to clarify the variables that might be considered

as well as the information needed to assess the variables. For example, suppose that a

designer is developing a DSS to help investors. As a starting point, the designer knows that

there are quantitative models that can be used to describe the

financial

market and to forecast

changes in the market. Similarly, the designer knows that the decision makers will rely on

some expert judgment about the financial market. These quantitative and qualitative factors

will influence the decision about how to invest. Of

course,

even with the best forecasts and

qualitative judgments, there may be sudden changes in the many factors that influence the

market, including events that change assumptions or even news that appears to change those

assumptions. In other words, the range of information and models that need to be included

in the DSS for this relatively straightforward situation can be very complex. Designers,

then, use influence diagrams to keep track of the factors that need to be included in a DSS.

Influence diagrams have few symbols and rules and so are easy to draw once the

conditions are well understood. First one must consider the variables of the decision

itself.

There are decision variables that are controlled by the decision maker, outcome variables

PLANNING FOR DECISION SUPPORT SYSTEMS

325

The decision.

A chance variable that

is out of the control of a

decision maker.

>

The objective of the decision.

This is the variable the

decision maker is attempting

to maximize or minimize.

A deterministic function of the

quantities that depend on it or

an intermediate variable.

>

Influence.

Figure 7.6. Influence diagram symbols.

that represent the outcome of the decision, exogenous variables that influence the decision

but are not under the control of the decision maker, and intermediate variables that are

evaluated between the decision and the outcome. To map those into an influence diagram,

consider Figure 7.6, which shows the symbols that can be used in an influence diagram.

As shown in this figure, there are symbols corresponding to a decision (a rectangle),

exogenous variables (an ellipse), intermediate variables (a rounded rectangle), the outcome

variables (an elongated hexagon), and the influence (an arrow). Using these symbols, one

can diagram the factors needing representation in the DSS. Consider again the example

DSS in the previous paragraph. These relationships are shown in an influence diagram in

Figure 7.7. See that the ultimate goal is (to maximize) profit (as shown by the hexagon).

The decision that will impact profit is the investments shown in the center (rectangle).

The decision maker comes to the decisions about investments after consideration of the

quantitative models (the left rectangle) and expert judgment (the right rectangle). Of course,

in making these choices, it

is

necessary to keep an eye on the events and relationship changes

in the environment. This tells us the kinds of information needed in the

DSS.

Each of these

decisions can be broken down into more detail to determine specific information, specific

variables, and specific models that might be included.

There are computer tools that can help designers build these diagrams and use them

to create the system. For example, consider Lumina's Analytica, which builds influence

diagrams easily, as shown in the top portion of Figure 7.8. These tools can then provide the

backbone of analysis using the functionality built within Analytica, as shown in the bottom

portion of Figure 7.8, or provide a blueprint for analysis with other modeling tools.

Situational Analysis.

Once an initial analysis of the key decisions and related

information needs has been completed, designers must complete a situation analysis to

help identify some of the remaining needs. This includes an analysis of the task, the

Mathematical

analysis and

forecasts

Expert

financial

judgment

DESIGNING A DECISION SUPPORT SYSTEM

Figure 7.7. An influence diagram.

organizational setting, and the user characteristics and how each contributes to the infor-

mational requirements of the DSS.

Using either interviewing or other techniques, a designer completes a task analysis

to identify the baseline information and model needs. The baseline needs represent the

theoretical or conceptual information needs that everyone would need without consideration

of the preferences of the decision maker or external needs imposed by the choice context.

These needs are driven by the nature of the tasks, their relative structure, variability, length,

and frequency to identify information needs and sources as well as constraints. Simon's

stages of decision making can provide insight into these needs. If

the

decision maker's goal

is "intelligence," the system must monitor and scan data to identify indicators of problems

and opportunities, such

as

trends, patterns, or exceptions

to

patterns.

For

example,

a financial

DSS might continually scan the stock and bond market for investment opportunities that

have high potential

payoff.

On the other hand, if the goal is "design," the system must be

able to facilitate the identification and construction of alternate strategies. In this case, the

DSS needs to provide opportunities for investment, such as tools for identifying mutual

funds with characteristics that will meet the needs of the investor. Finally, if the goal is

"choice,"

the system must facilitate evaluating and testing of the alternatives for sensitivity to

assumptions. In this case, the

financial

DSS might evaluate alternatives for past performance

as well as the expected reaction of the financial opportunity to changes in

resources,

political

climates, or other factors that could affect its desirability.

Similarly, the task analysis determines whether there are limitations on the number

or types of models appropriate or necessary in the analysis. For example, in the case of

the investment executive, task analysis identifies the need to distinguish between deciding

when to invest, how much to invest, and for how long to invest as well as the outcomes of

liquidity, rate of

return,

and total profit. In addition, it reminds us to consider related factors

such as the inflation rate, competition, and market stability.

Once we know the main independent, dependent, and interdependent aspects of the

choice context, we can begin to understand what the decision maker needs to do,

what

the

decision maker can control, and what constrains the decision maker's actions. Designers

PLANNING FOR DECISION SUPPORT SYSTEMS

327

Figure 7.8. An influence diagram in Analytica. Example screen shots were provided by and

reprinted with the permission of Lumina Decision Systems.

328

DESIGNING A DECISION SUPPORT SYSTEM

must learn what guides and limits the decision maker as well as what measures are ap-

propriate for assessing the quality of the decision and/or outcome. Knowing the facets of

the problem and the interdependencies among them will help identify information sources,

authority constraints, and coordination necessary to provide decision makers what they will

need.

The organizational setting analysis describes the forum in which the choice will take

place. In this analysis, designers identify informal norms or other relevant practices for

analyses as well as the climate in which the decision maker functions and relevant rela-

tionships among the decision makers within their organization. Each of these evaluations

results in information and modeling needs for the DSS.

Finally, designers need to examine the user characteristics, such as the amount of

experience and knowledge possessed by the decision makers and the extent of their skills.

As we saw in Chapter 2, this is influenced by the experience and background of the

users concerning the problem type under consideration with the models appropriate for

that problem and with DSS or other computer-based tools. Further, this is influenced by

information preferences, decision-making styles, and approaches to problem identification

and evaluation. Knowledge of the user requirements along all of these dimensions will

provide insight into the information needs (primarily background needs) as well as into the

model management and other user interface requirements.

The entire situation analysis results in a deeper understanding of how the DSS will

be used, including the kinds of information, models, support, and intervention the user is

likely to employ. To achieve this understanding, designers develop a model of how decision

makers will use information. They identify a basic understanding of the model through

the identification of baseline needs. This model is refined by interviews and observation of

the decision makers. Designers abstract important information from those interviews and

compare the expressed needs to those predicted by the model. Differences between the

expressed and predicted needs are used to refine the model. Often these steps are followed

in an iterative fashion, with designers forming and refining models of the decision makers'

needs between data collection steps, as shown in Figure 7.9.

Designers should be able to understand how the decision maker conceptualizes, an-

alyzes, and communicates problems. For example, at this stage, designers should be able

to learn where and how decision makers will employ graphs, lists, charts, and other aids

Perform initial interviews

Pick basic model

<-

Perform model-directed interviews

<■

Perform data abstraction

<

Figure 7.9. Interative nature of situation Check fit of model to data

analysis. I

PLANNING

FOR

DECISION SUPPORT SYSTEMS

to understand the problem.

In

addition, designers should know how decision makers ana-

lyze and manipulate the information

in

different contexts. This includes understanding the

representations (i.e., the lists, graphs, charts, etc.), operations (i.e., the means

of

analysis),

and the linkages between representations and operations as well as the model management

tools,

note pads,

or

user interface components that facilitate those linkages. Finally,

the

situation analysis suggests frameworks

for

making the DSS useful

to

decision makers.

In

particular,

it

suggests characteristics

of

the user interface,

its

design,

the

necessary kinds

of intelligent and context-specific assistance, and the relationships between modeling and

database components. Said differently,

it

would tell the designers how to evaluate the four

components

of

a DSS discussed in earlier chapters.

The

end of

the situation analysis begins

the

design phase.

As

shown

in

Figure

7.9,

the design stage begins with

a

logical design

of

the system and ends with the construction

of the system. In particular, this includes the identification and/or creation

of

(a) available

databases

and a

database management system;

(b)

available models

and a

model base

management system; (c) user interfaces, and (d)

a

mail management system.

In

this step,

designers determine how the system will work and what hardware

is

appropriate. Further,

they must identify what software

or

tools

to

utilize

or

create. Finally, they must identify

an appropriate design approach. Advantages and disadvantages of different approaches are

discussed in the next section.

After the construction

of

the system, designers must evaluate and then implement the

DSS.

This stage includes testing

of

the system and evaluation

by

the designers

as

well

as

the users. Implementation includes training, deployment,

and

demonstration.

Of

course,

the final stage

is

maintenance

and

adaptation. Maintenance covers

the

correction

of

any

defaults

in

the system that appear after deployment

of

the system.

In

adaptation designers

modify the system in response to changing demands upon the choice process resulting from

new choices or information sources or they make improvements in usage of the system.

As with the SDLC, there have been several attempts to provide methodologies which

specify the various steps in the design of

DSS.

Among these are

ESPIRIT and KADS

from

the University of Amsterdam. Each of these follows the basic structure outlined in this chap-

ter, but they provide additional details and specifications for completing the analysis phase.

Design Approaches

Table 7.1 outlines the three approaches to design and implementation. These three methods

suggest that you either build the whole system from scratch ("one stage, complete system")

or

use

current technologies

to

facilitate

the

development ("quick-hit method"

and the

"evolutionary method").

In

addition, they suggest that you either treat the DSS

as a

one-

time development, with some maintenance over time ("one stage, complete system"

and

the "quick-hit method"), or you plan for the system to grow with the demands placed upon

it ("evolutionary development").

Systems Built from Scratch.

The one-stage, complete-system approach assumes

that nothing, including the models, the model base management system, the databases, the

Table 7.1. Design Approaches

One-stage, complete system

Quick-hit method

Evolutionary development

DESIGNING A DECISION SUPPORT SYSTEM

database management system, the user interface—or even their components—is available

on which to build the desired DSS. As the name suggests, this approach requires the

designers to build an entire system and deliver it in total to the decision maker. In these

cases,

designers use the DSS-adapted life-cycle approach, shown earlier in Figure

7.3,

with

significant emphasis on the design and construction phases. It means that designers code

every aspect of the system from one or more languages without the benefit of available

electronic tools or modules. Although all early DSS were built in this way, today, the one-

stage, complete system is implemented only when building a large-scale, multiple-user, or

unique system.

This approach is useful when the models are so specific to the problem that modeling

software is not available. For example, suppose the purpose of the DSS is to facilitate

decisions regarding battlefield logistics and strategy. Or suppose the DSS must simulate

human tolerance of toxic wastes. The necessary models are sophisticated and unique,

libraries of such models do not exist, and the models may be quite complex. Since the

model is such an important part of the DSS, it may be easier to build the system around the

specialized model than to incorporate it into preexisting tools and modules.

The best generalized example of the use of a one-stage, complete system today is the

design of geographic information systems (GIS). These systems provide decision support

for a particular class of problems, namely those requiring map-oriented analyses of data.

For example, city planning agencies may need to track sewer development, electricity

and gas hookups, movement of the population, and housing starts. For some analyses and

decisions, it may be most meaningful to model the infrastructure to support housing starts

with a map. In this case, the map and the associated analysis tools serve as the model and

model management tools. In other words, the GIS is a DSS that uses a specialized set of

models and model management capabilities, specialized database files, and a powerful user

interface. Since these tools require a unique programming platform at this time, this form

of DSS is designed as a one-stage, complete system today, especially because of the fact

that the tools are generally used in isolation. The specifics of

a

GIS and its applications will

be highlighted in a later chapter.

When using the one-step, complete-system method, designers often prototype as a

means of determining system requirements. A prototype is

a

facsimile system that simulates

the user interface as well as the data and modeling activities of

the

DSS.

Designers develop

prototypes using fourth-generation languages or other prototyping tools that allow rapid

development and easy change of the system. After decision makers specify the basic

needs and preferences, designers can quickly produce a prototype that they believe meets

those needs and preferences. Users then operate the prototype as they intend to use the

ultimate system. In this way, they experience the user interface, data management, model

management, and mail management features and capabilities. Since users can demonstrate

problems or less preferred options for the designer, they can also respond to specific

features or constraints and express their concerns more precisely. Similarly, designers can

ask questions in an unambiguous manner.

Designers armed with this feedback can adjust the prototype quickly to respond to the

users'

needs. Since the elapsed time between the expression of preferences and observation

of the effects is so short and since specific system attributes are identified, users can focus

on whether designers understood and implemented their concerns. This cycle is repeated

until the user is satisfied with the design of the entire DSS.

The prototype enables designers and users to communicate concretely, reducing the

chance of miscommunication. Such a tool is important because the designers and the

decision makers have different mental representations of the problem which bias how they

respond to new information provided to them about the system. The tangible nature of the

PLANNING FOR DECISION SUPPORT SYSTEMS

prototype allows them to look for disconfirmatory data which identifies when the DSS is

not performing adequately. While many seasoned designers prefer an intuitive approach,

this empirical way to determine needs will generally provide a better analysis of decision-

making needs.

After a satisfactory system has been created, the designer could translate the fourth-

generation code into more efficient and easily maintained production code. This would

have the benefit of providing a system that could be maintained over time and that could be

used by multiple users without magnifying the strain on resources. However, it introduces a

time delay in users' access to the real system. Further, since production code may not have

the same capabilities as are available in the fourth-generation languages, some important

features can be lost. More often, designers leave the DSS in the fourth-generation language

and allow users immediate access to the technology. If there are few users, particularly if

they do not use a system frequently or intensely, the advantage of improved efficiency in

code is not worth the delay.

Although the one-stage, complete-system method was once the preferred approach to

design, it is unusual to use this approach to DSS design today. The change is associated

closely with the move from file processing applications toward database applications in

most corporations and organizations. In earlier periods of data processing history, most

applications had their own unique data that ran with the system, and hence the need to

identify data and control it was associated with the DSS

itself.

In today's environment,

there has been a move toward

shared

databases. Certainly most large computer users

have shared data to both simplify control and access to the data and make results across

applications consistent. Further, this shared view of data allows more types of data to be

available for a greater number of applications and therefore makes possible richer decision

making. Today increasing numbers of models are computerized and easily integrated within

a DSS. Since these sophisticated databases, models, and their control mechanisms exist, it

would be inefficient to design without them.

Access to a wide range of databases has made the DSS more useful. However, it has

also led decision makers to make greater data demands on the systems. Fortunately, with

the greater connectivity available through the Internet and the capability of "surfing" the

Internet, decision makers can get access to broader data in shorter times.

Simultaneously, there has been

a

change in the capability of hardware and the efficiency

of the software provided as DSS appliances. Early appliances were quite limited in the

range of models and data they could reach, were relatively inefficient in their analyses, and

provided user interfaces that would

be

considered archaic

today.

Today, designers can realize

significant economies of scale from centralizing the development of such sophisticated

tools,

such as those provided with Cognos, shown in Figure 7.10. If such centralized tools

are implemented properly, it can result in the development of a very efficient engine and a

system that integrates well with other systems.

Furthermore, since tools are substantially more sophisticated today, building them from

scratch is likely to be a long, tedious effort which most corporations cannot tolerate. The

resulting system would be both late and technologically obsolete before use. In short, the

resources available to DSS designers are substantially better today than they were in the

past. Hence, where the resources exist, it makes sense to use them.

Using Technology to Form the Basis of the DSS.

The other two approaches to

designing a DSS differ from the first in that both rely upon the use of an existing base

technology, called a DSS appliance. In the one-shot, complete-system approach, designers

customize all the components by building them from a language. More often, designers use

commercially available, leading-edge tools and technologies to construct the system more

332

DESIGNING A DECISION SUPPORT SYSTEM

Figure 7.10. Example DSS appliance-Cognos. Screen Shot provided by and reprinted courtesy

of International Business Machines.

quickly. These tools and technologies are referred to as "appliances" for the DSS, or DSS

appliances.

EVALUATING A

DSS

APPLIANCE.

Of course, designing more quickly is only good if

the appliance will, in fact, meet the needs of the application. Said differently, it will only

be appropriate to use an appliance if it allows the uses and functionality that are anticipated

for the DSS, such as those described in earlier chapters. These needs must be stated before

purchase or lease. Certain issues must be considered for any appliance, such as those

summarized in Tables 7.2-7.7.

The needs summarized in these tables correspond to the DSS needs discussed in earlier

chapters. For example, Table 7.2 shows some features to consider regarding the database

and data management component of the DSS. From a macroperspective, we need to ask

whether the appliance will simplify or prohibit access to and manipulation of the necessary

data. Unfortunately, it is not always easy to determine

what

data will be used or even

how the demand for data will expand as the DSS is used. So, designers need to take the

perspective of the decision maker when asking whether the appliance is adequate, flexible,

and usable and provides sufficient security to meet the needs of the application.

In particular, the designer needs to consider whether the appliance (a) is consistent

in providing data (both in raw and processed form) to users, regardless of the source of

the data; (b) interfaces well with the corporatewide data management tools; and (c) allows

data warehousing. In other words, adequacy reflects whether the appliance will provide

users access to the necessary data in a seamless and friendly fashion. Further, the appliance

must be flexible in its use of data to meet the varying needs of decision makers. For

example, earlier chapters discussed the importance of allowing development and use of

PLANNING FOR DECISION SUPPORT SYSTEMS 333

Table 7.2. Data and Data Management Concerns in Selecting a DSS Generator

Adequacy

• Provides common user view of data

• Links well to corporate database management system

• Facilitates data warehousing

Flexibility

• Offers the creation of

"personal"

databases

• Supports a wide range of database formats (text, graphics, audio, video, etc.)

• Facilitates ad hoc query capability

• Provides flexible browsers for public databases

• Facilitates knowledge management

Usability

• Offers ease in data selection

• Has data dictionary

• Handles necessary amount of data

• Can handle sparse data

Security

• Provides data security features

• Offers multiple levels of security

• Controls number of

users,

with what kinds of

access,

in simultaneous use

• Creates audit trails

personal databases exclusively by the decision makers. The appliance must allow such

development and provide full tool use on these data. Similarly, decision makers must have

a tool that searches public databases using the full range of query development they use

in the corporate databases. An ideal system would provide the same search engine for all

databases, thereby making transition from one type to another transparent to the user. In

addition, the appliance must allow for formats beyond simple text. Depending upon the

application, decision makers are likely to need graphics, audio, video, and even access to

virtual reality files. These alternate format files can only be effective support mechanisms,

however, if they can be indexed, stored, and retrieved easily and merged with other data.

Usability refers to the system's ability to meet data and decision maker needs. On the

one hand, the question of usability can refer to the size of databases, the size of resulting

tables,

or the number of queries that can be made at once. Since size and price are often

highly correlated, we need to be sure of buying enough to meet foreseeable needs. On the

other hand, the question of usability can refer to the decision maker's ability to find the

necessary variables and to make the system understand those variables.

Finally, any corporation needs to provide security for certain data. Users expect the

DSS will ease the problems of location of information and

reports.

With this ease, however,

comes the requirement that the appliance prevents those not employed by the corporation

from using the data. It is also true that some data are so important or controversial that only

some members can have access to it on a "need-to-know basis." Hence, the appliance must

be able to provide multiple levels of security as well as necessary audit trails to determine

who has gained access to what data.

Similarly, designers need to evaluate these issues with regard to the models and the

model management system associated with the DSS appliance. The appliance needs to meet

334 DESIGNING A DECISION SUPPORT SYSTEM

Table 7.3. Models and Model Management Concerns in Selecting a DSS Generator

Modeling

• Functionality

(a) User-defined functions

(b) Procedurability (ability to solve equations independent of their ordering, symbolic reference

of data)

(c)

A

Wide range of functions

(d) Nonprodedurality

(c) Time as

a

possible dimension

• Flexibility

(a) Size restrictions

(b) Currency and date conversions

(c) Ability to aggregate and disaggregate analyses

(d) Ability to link sequential analyses

(e) Multidimensionality

(f) Links well to available modeling packages

• Appropriateness of included models

(a) Symbolic modeling

(b) Statistical ability (descriptive statistics, hypothesis testing, predictive statistics, regression)

(c) Project management ability (PERT/CPM, multilevel work breakdown structure)

(d) Operations research ability (mathematical programming, stochastic analysis)

(f) Forecasting and econometrics ability (time series analysis, causal modeling, seasonalization,

smoothing)

• Ease of

use

Analysis capabilities

• Sensitivity analysis

•

"What-if"

analysis

• Impact analysis

Note:

PERT is program evation and review

technique;

CPM is

critical

path

method.

both the modeling and analysis capabilities of the decision makers, such as those described

in Table 7.3. In this case, the modeling concerns address whether the appliance can handle

the kind and size of models that are of interest to the decision maker. In particular, it

examines the models that can be accessed, the ease of use, the flexibility (especially with

regard to size), and the functionality made available in the system.

The analysis capabilities, on the other hand, question the appliance's ability to provide

the decision makers with a rich modeling environment. The characteristic of a DSS that

distinguishes it from (being simply) a modeling package is its ability to simplify both the

use and the interpretation of the models. For example, the model management component

needs to be able to use the output of one analysis as the input to a second analysis, if

wanted. In addition, the appliance must allow and simplify appropriate sensitivity and

"what-if"

analyses associated with the models in its portfolio. Not only must it tolerate

review of the assumptions and rerunning of models in light of changes in the assumptions,

it also must encourage the user by providing an easy path to such analyses and a user-

friendly interpretation of the output. Finally, the appliance needs

to

provide context-sensitive

modeling assistance for the user. This does not mean the online version of the user manual

as exists in many PC-based applications today. Rather, this is a level of assistance in how

to run the model, including a statement of the assumptions and limitations of the model

PLANNING FOR DECISION SUPPORT SYSTEMS 335

Table 7.4. User Interface Concerns in Selecting a DSS Generator

User friendliness

• Novice and expert modes

• Menus and Prompts

• Consistent, natural language commands

• Command abbreviations

• Context-sensitive Help

• Clear, end-user-oriented error messages

• "Undo" command support

• Meaningful identifiers

• Documentation

• User-defined commands

• Context-sensitive warnings

Support of modeling and data needs

• Wide range of graphics support

• Windowing support

• Multitasking support

• Support for a variety of input and output devices

• Color and functional control over user interface

• Support for individual customization

Graphics

• Quality and resolution of output

• Multicolor support

• Range of output control

• Support for dynamic graphics, video and audio enhancements

• Basic plots and charts

• Complex charts

• Format and layout control

• Spacing of graphs

• Compatibility with available graphics devices

• Preview ability

• Modification ability

• Ease of use

Reporting formats

• Supports a range of platforms

• Flexibility of reporting formats

• Standardformats

• Ease of customization

• Standard symbols and conventions

and even an intelligent intervention when modeling assumptions have been stretched or

violated. While most appliances will not have such assistance built into the package, a good

one will simplify the development of such tools.

Consideration of the user interface capabilities is important as well. Table 7.4 refers

to those needs outlined in Chapter 5. In particular, in order for the system to be helpful

for the decision maker, it must be user friendly (whatever the level of user expertise and

experience); support a wide range of output and input devices; provide graphical, video, and

DESIGNING A DECISION SUPPORT SYSTEM

Table 7.5. Connectivity Concerns in Selecting a DSS Generator

Compatibility with available electronic mail system

• Document sharing

• Data sharing

• Communications

• Mail-handling and priority-setting code

Connectivity to Internet

resources,

including news services, and

Web

pages

Electronic searching devices for Internet resources

Firewall availability

audio interpretation of the results; and provide a reporting format that can be customized

for the specific application and/or user under consideration. From the designer's point of

view, this means that the appliance must either provide such functionality itself or make

it easy to design.As with any software adoption, we need to be concerned that the system

will work in our environment and will be affordable and can be upgraded over

time.

Tables

7.6-7.8

summarize criteria to consider for ensuring the selection of the appliance makes

good business sense.

Table 7.6 illustrates the issues associated with basic compatibility

issues.

It

is

important

to ensure that the appliance will work with the equipment available and with the operating

systems and networking options available. In addition, it must be able to work with any

additional resources acquired, including input, output, and storage devices.

Table 7.7 illustrates the cost issues associated with the use of the appliance. Today,

software can be purchased or leased using a variety of options. Designers must examine

these costs carefully to ensure they are in line with the usage patterns of decision makers.

For example, it is not appropriate to deploy a product across many occasional users of

a system if the cost is based upon each installation of a developed product, especially

if it is not possible to deploy those copies via a network. On the other hand, it would

be appropriate if the cost were a function of the number of simultaneous users of the

product.

Finally, Table 7.8 illustrates issues that should be considered to ensure that the vendor is

reputable and is likely to provide the kinds and level of support needed for your application.

Such support will be important not only during the development stage but also as users

begin to find undocumented features needing explanation.

USING A

DSS

APPLIANCE.

If a DSS appliance forms the basis of a DSS, a designer

has two possibilities for development, the quick-hit approach or the evolutionary approach.

Table 7.6. Hardware and Software Concerns in Selecting a DSS Generator

Compatibility with available equipment

Compatibility with available operating system

Compatibility with available networking configuration

Printer and plotter support

Preferred hardware/operating system/networking configuration

Time-sharing option

Disk and other resource requirements

PLANNING FOR DECISION SUPPORT SYSTEMS 337

Table 7.7. Cost Concerns in Selecting a DSS Generator

Initial purchase/license cost

Per-capita fee

Maintenance costs

Documentation

Resource utilization

Conversion costs

Upgrade frequency and costs

The difference between the two is in the staging of development and the basic involvement

of decision makers in the design process.

The goal of the quick-hit method is to design a system

quickly

in response to some well-

understood and usually immediate need that is expected to have

a

high

payoff.

Furthermore,

the system is likely to reside on a microcomputer and be used by either one person or a

small group. The goals and procedures are clear, the data are available, the system can stand

independently, and there is little need to address conflicting concerns. Hence, much of the

analysis component of design can be done quickly. Further, since the system is discarded

after the choice is made, it is not necessary to employ many of the procedures necessary

that ensure the long time viability of a DSS.

We might use this approach to design a DSS for a problem such as a high-level

personnel decision. In some industries, many of the criteria needing evaluation are well

known. Furthermore, selecting the right person for the job can save corporations significant

money and provide significant opportunities for growth. However, it is a decision that is

not made often. Hence, a DSS to support a choice would be a good candidate for use of a

quick-hit design process.

To achieve the goal of fast deployment, designers rely heavily upon already available

tools and packages, existing data and model sources, and existing data, model, and mail

management systems. Such systems work well in the short run, because designers can

rely upon tested components that use the current technology. However, over the long run,

designers only may be able to update, maintain, or enhance the system when the vendor

Table 7.8. Vendor Concerns in Selecting a DSS Generator

Financial stability and viability

Length of

time

in business

Size of installed base

Growth in customer base

Quality and size of staff

Activity of

R&D

staff

Ongoing commitment to this product

Technical support personnel

Availability of support hot line

Availability of Internet-based support

Time horizon for support

Internet user discussion group

Organized user group

Product target market

User perceptions

DESIGNING A DECISION SUPPORT SYSTEM

provides updates to the appliance. In addition, the vendor dictates the kinds of enhancements

provided in the system. Alternatively, if the system

is

composed of

a

makeshift combination

of existing tools and systems, the processing efficiency may not be as good as it can be

with more structured systems. Of course, in the long run, it may be difficult to bridge such

systems to other existing systems or to systems introduced later.

The quick-hit process relies heavily upon the use of appliances and other tools so that

the designers can focus their energies on the analysis and user interface components. Such

a process is reasonable if the system can stand independently and if the data are already

available. However, it becomes difficult if there is a long-term need for the system or a need

to tie it to existing systems. The approach only works if users know what kinds of data and

models to use and do not need significant levels of "support" in either the data selection or

modeling phases. In fact, it works best if the need is so domain specific that a particular

modeling package can be used as the core of the system.

The third approach, evolutionary development, is similar to the quick-hit approach in

that it is dependent upon the use of DSS appliances, which allow for quick development

and quick changes. Further, they allow the designer to focus on analysis of

the

needs rather

than on construction of the software. Evolutionary development differs from the quick-hit

approach in that designers expect the system design will mature as decision makers gain

experience with the system and the information access.

Evolutionary development begins when the designer selects an important subproblem

of the choice process. Through focus on this subproblem, the designer learns about the

information, modeling needs, and user interface needs of

the

decision maker. This subprob-

lem must be small enough to be unambiguous to both the designer and the decision maker

but large enough to require computer support. In addition, the problem must be important

to the decision makers so that they will participate closely in the development process and

adopt the process after design.

The process of design is heavily dependent upon the use of prototyping, discussed

earlier in this chapter. Designers begin by seeking user needs. From this information, they

design a "quick-and-dirty" but working mockup of the system. Decision makers test and

evaluate the prototype and refine their information needs. Designers then fine tune the

system and provide it to decision makers again for testing and evaluation. This process is

repeated until the evaluation calls for no substantive changes and an acceptable and stable

product is available to the decision maker.

The key to this being different from the first process defined is twofold. First, unlike

the one-step, complete system, it builds all components from scratch. As such, there is

often a delay between the agreement of specifications and the provision of

the

product. The

evolutionary approach, on the other hand, provides decision makers with a working system

quickly. However, rather than providing the entire system at once, the evolutionary system

provides only a small component of the eventual DSS at the outset. This allows users to

experience using the system with the agreed-upon specifications and hence to be able to

change those specifications as the system matures.

In addition, when prototyping is used in the one-step, complete method, it generally is

not a working system but rather a mockup using a shell tool, a limited database, and a stand-

alone machine. Often, response is better with these prototypes (in terms of both quality

of the response and response time) than the designers can provide with the production

language. As a result, users are often disappointed by the final system. In the case of the

evolutionary development, designers use appliances, not mockup shells, in development.

Hence, what the user sees when interacting with the system early is what the user sees

with the eventual development system. Furthermore, since designers and decision makers

PLANNING FOR DECISION SUPPORT SYSTEMS

concentrate on one small part of the process in the prototyping effort, it is easier for both

parties to concentrate on the implications of features and changes to features. In addition,

because the evaluation of

the

system and changes requires less of

the

decision makers' time

(because it is smaller), they are able to provide better and more meaningful feedback to the

designer, and thus the exercise tends to have better results. By focusing on the small but

important component of the process, decision makers can understand the implications of

their suggestions better. In the one-step process, designers and decision makers dilute the

focus by looking at the entire system at once. Since there is so much to look at, decision

makers may not consider how many of the functions will actually work in a production

system. Decision makers may not commit the amount of time, energy, or attention to

understanding the entire system at once.

The problem with the evolutionary development is, of course, where to start. Clearly,

we need to begin with some component of

the

problem that is of importance to the decision

maker. Once that decision is made, however, the designer still needs to determine what

information should be included at the outset. However, information is not a unidimensional

concept. Suppose decision makers state that their most important focus is on effectiveness.

While "effectiveness" of the alternatives might seem like an unambiguous concept, it can

really mean very different things to different people. To the designers, it might mean cost

effectiveness. To the decision maker, it might mean the expected outcome of attracting new

clients. Even if there is agreement on the measure "attracting new clients," there might be

disagreement about when relevant data are actually information. For example, designers

might think of hard numbers of new clients and thus new sales. However, decision makers

might think of an increase in customer satisfaction that will lead, in turn, to acceptance of

the product.

Ultimately, all these views might be important to the decision maker. Nevertheless,

designers need to know where to start. To define the needed information, designers must

look at it from a variety of perspectives: (a) the content, (b) the representation, and (c) the

attributes of the data themselves. An understanding of the appropriate content means an

understanding of what knowledge needs to be accumulated and maintained or what issues

need to be addressed. Here, for

example,

the designer determines if the most important issue

is the attrition rate, the schedule needs, or the advertising expenditures. In addition, the

designer must differentiate the relevant perspective of that content. For example, designers

need

to

determine if decision makers prefer

the

function or merit associated with the relevant

content. If one considers the topic of "advertising expenditures," a "function" perspective

would represent how the money was spent, where the money was spent, and so on, while

a "merit" perspective would represent how the expenditure had an impact on the clientele.

Similarly, designers need to determine the focus of the information, or whether the data

should be oriented toward how the alternative is structured (an internal focus) or upon

the service that is provided by the alternative (an external focus). Third, designers need

to understand what kinds of measures are most important to the decision makers. This

might include cost data, activity data, performance data, or impact data. For example, the

data needs are quite different if decision makers simply want to know on what kinds of ads

money is spent than if decision makers want to know what market segments are reached and

are likely to be influenced by the information. The representation of data has traditionally

included the format, or the presentation of what kinds of data in what order. This would

include whether graphs or charts are provided, icons or text, and numbers or conclusions.

Finally, the attributes of the information are those characteristics discussed in Chapter 3.

This includes whether the data are qualitative or quantitative, facts or judgments, specific

information or global generalizations, past performance or expected performance data. In

DESIGNING A DECISION SUPPORT SYSTEM

addition, it includes a specification of who provides the data and what kinds of credibility

go along with that presentation.

Once one can describe the content in this multidimensional manner, it is possible to

provide guidance as to how to start the DSS design and how to let it evolve. Fortunately,

the dimensions cluster together, making it easier to determine where information will be

most useful. For example, the content and representation of the data required often are a

function of the experience level of the decision makers. As decision makers gain greater

experience with

a

particular

type

of decision, they move from seeking feasibility information

to preferring information regarding the performance of alternatives under consideration;

with increasing amounts of experience, they tend to move toward information regarding

the efficiency of alternatives. A similar shift occurs with regard to the attributes of the

information. Decision makers with little experience tend to seek quantitative, factual data

that reflect future economic implications. As decision makers gain more experience, they

seek more information regarding the past performance of alternatives, usually in terms

of qualitative information and more speculative opinions. Finally, decision makers with

significant amounts of experience tend to address process issues. They seek quantitative,

factual data, reflecting the operations issues of the adoption of the alternative.

These preference patterns can be useful for guiding the evolution of systems. For

example, if it is known that users are primarily inexperienced in a particular category of

decisions, it would be wise to emphasize feasibility information with factual data reflecting

the economics of the environment in the early stages of development.

In addition, decision makers' preference for analytical methods evolves over time as a

function of how the decision context changes. For example, decision makers are likely to

employ compensatory models, such as optimization models, only when considering tactical

decisions in a stable environment for which the user has significant experience. Knowing

this suggests a need for including many exploratory and statistical tools in the early stages

of DSS development and can deemphasize other kinds of tools until later stages of the

evolution of the system.

The Design Team

Selecting the appropriate design approach and the appropriate technology clearly are im-

portant aspects of DSS design. A third concern is selecting the appropriate project team to

meet the needs of the system. This is particularly important for the

first

DSS in

a

corporation

or group and/or if the DSS is part of a strategic change to the corporation.

First, the team must include a champion (even if it is simply an ex officio position)

from among the senior management of the group. Including such a person and keeping

him or her updated regularly can help you to get the necessary access to resources, data,

and models. In addition, you need a team of developers with the appropriate skills. For

most DSS applications today, this team needs to include people trained in the graphical

and object-oriented technologies who are open minded and imaginative. However, it is

important to include people who understand the issues associated with disaster recovery

and security. Planning for problems from the start makes it much easier to solve them.

Finally, it is important to include end-user decision makers on the team to ensure that the

DSS meets their decision-making needs.

Whether internal end users or external consultants, team members need to have certain

characteristics, such as those outlined in Table 7.9. Notice that the primary team need

is a sense of creativity and open-mindedness. If the DSS is to result in better decisions,

the team must do something more than simply automate the current procedures. If team

DSS DESIGN AND REENGINEERING 341

Table 7.9. Characteristics of Good Team Members

Creativity and openmindedness

Good communication skills

An understanding of

the

decision task and the organization, business,

and marketplace.

An understanding of

and

experience with DSS design and/or use

An understanding of

possible

technology

A willingness to work cooperatively

Good chemistry between the design team and the use team

members do not have the capacity to see potential opportunities for change, change will

not occur.

A second need is good communication skills. Later in this chapter, we will discuss

the problems associated with putting decision needs into words. In addition, it is difficult

to communicate technical requirements or enabling technology. Without good communi-

cation, no creative change to the decision process can happen. A humorous example of the

kind of miscommunication that can occur is found in the accompanying box.

Similarly, the team needs to have a good understanding of the decision task, how that

task fits within the organization, and how it relates to the business and the marketplace. The

goal of the exercise is to provide a value-added service through the DSS.

DSS DESIGN AND REENGINEERING

In today's business environment there is considerable discussion about business process

reengineering (BPR). The term was coined by Hammer (1990) to mean the radical redesign

of business processes to achieve dramatic performance improvements. The redesign typi-

cally uses modern information technology and changes of the focus of decision making so

that it crosses functional and departmental lines. BPR requires (a) the organization of ac-

tivities around outcomes (not tasks), (b) decision making at the point of work performance,

and (c) the development of adequate control processes. Finally it requires that information

Computer people often arc guilty of talking only in acronyms. This can be intimidating to the

user who may not understand the acronyms and hence cannot fully understand the problems or

opportunities that are being presented. However, il can also be contusing when the end user has

similar acronyms and does not understand how they are being used differently.

One of

the

best examples of this was observed when an external consulting learn developed

a

DSS

for

a

large,

progressive

hospital.

Part of the development team

met with a

committee of

the

nurses and nursing supervisors to design one component of the system. During this discussion,

designers kept referring

to the

I/O and

how

it would

change.

The nurses

were

obviously becoming

more and more confused until one of them asked,

"What do the patient 's liquid inputs and liquid

outputs have to do with how we can make better nursing

decisions?"

In other

words,

they were

baffled because "I/O" had a meaning to them but did not have the same usage as that of the

consulting team,

DESIGNING A DECISION SUPPORT SYSTEM

be captured only once, at its source. Much has been written about the reengineering process

and how it is conducted, but it will not be repeated here since that is not the purpose of this

text. However, since BPR has an impact on decision making and the use of technology, it is

reasonable to question the relationship between the design of DSS and BPR. In particular,

we will address three questions.

• Is DSS design BPR?

• Does DSS design require BPR?

• Can DSS design facilitate BPR?

Clearly, DSS design is

not

the same as BPR. Although technology and its rapid

development are the enablers to achieving the goal in both cases, the goals of the analysis

and the expected outcomes are quite different. Business process reengineering, by its very

nature, focuses on the fundamental activities of

a

department or organization, the processes

necessary for their completion and improvement, and the activities that would improve the

flow of work in the organization. This might include an analysis of what information and

what models are available to whom, but the more likely focus would be on who makes the

decision, how decentralized the decision making becomes, and what controls are established

to ensure that it happens well.

Instead DSS design focuses on the process by which decisions are made. It does not

question whether or not the individual decision makers

should

be making the decision, does

not focus on most of the employees of an organization, and does not necessarily result in

a physical product or service being improved. Like BPR, DSS design does not have cost

cutting as its goal. Rather, its goal is a better thought-out choice process that often has as

a natural result a reduction in costs and losses. In addition, good DSS design, like good

BPR, can have a side benefit of improvements in corporate performance, because decision

making is improved. There clearly are parallels, but they are two substantially different

activities.

Second, does DSS design require BPR? Not

always.

Sometimes, designers and decision

makers intend for the DSS to only improve access to data and models but not to make a

fundamental change in how operations are conducted. In these cases, reengineering is not

an important component of the DSS design. However, at other times, the decision to move

toward a DSS is part of a corporate strategic decision. In such cases, the existence of a

DSS

alone

is unlikely to cause a substantial change in the way business is conducted. Just

throwing the power of a computer at a problem will not cause expected productivity gains.

As Hammer has said (1992 p. 104), "turning the cowpaths of most business processes into

superhighways using the plethora of computer hardware just doesn't work." That is, if all

the DSS does is to automate the current decision processes, and the decision makers have

only the same data, the same models, and the same charts as they have always had, this will

not improve decision making.

Instead, the DSS design needs to be coupled with a reengineering of the decision

process. The design process allows designers and decision makers alike to rethink the

choice process by considering explicitly what decision makers need to know and how

they need information presented. It allows an opportunity to take a holistic view of the

process, the natural way of considering choices, the neglected opportunities for insight and

possible integration strategies. The technological solution is not as significant as the way

the technology is used to implement an organization's strategic vision.

DSS DESIGN AND REENGINEERING

343

Third, can a well-designed DSS facilitate the BPR? The answer is Yes! The DSS

can be a resource that simplifies the reengineering effort. One of the major difficulties

in reengineering is the absence of necessary data. It is impossible to plan for change or

predict the impact of change without appropriate information regarding current operations

and current environmental data. Unfortunately, such data are not readily available in most

organizations. However, using a DSS can provide managers access to the data and means

for understanding them. The DSS can help managers to challenge old procedures and

create new ones through better alternative generation, more informed decision making,

and better use of models. In addition, decision makers can view a given problem from

a variety of perspectives and be better able to understand the problem, the assumptions,

and the implications of the solutions. With group DSS technology, decision makers across

functional areas can collaborate by sharing information, analyses, and models. The use

of DSS technologies can actually help the reengineering effort be more effective and

productive. (This topic will be discussed in more detail in Chapter 11.)

Although BPR and DSS design are two separate activities, they have similar aspects,

and therefore there are some lessons we can learn from BPR that have parallels in DSS de-

sign. First and foremost, communication during the process is crucial. Carr and Johanssen

(1995) indicate that communication is crucial in the beginning of BPR to assess the cultural

climate and the barriers to change and in the later stages for obtaining acceptance of the

changes so that the improved processes will not be sabotaged.

1

Furthermore, communi-

cation can help us improve the overall design by gaining from the experience of many

individuals through their comments and suggestions. This clearly is true with DSS design

as well. Without active communication, the designer will implicitly state assumptions of

the design process as:

• There is one best way to make decisions.

• I can understand how your decisions are made easily and quickly.

• Little about how you make decisions is worth saving.

• You will make decisions in the manner that the designer specifies.

2

While managers and other employees might not be as concerned about job loss as they

would be during BPR, there are concerns about making the task "too hard" or the perception

that managers were just not doing a good enough

job.

Forcing people into a new decision

style may not

be

productive. Table 7.10 shows some tenets of "good communication" during

BPR adapted for DSS design.

This leads to the second similarity between DSS design and BPR: There is likely to

be resistance to change. Concerns about uncertainly and additional workload affect both

DSS design and BPR. However, perhaps a bigger problem in DSS design (as compared

to BPR) is the fear of criticism. Most decision makers consider a specific set of issues

when they make choices. Some of those factors may use sophisticated models or grand

'For

example,

Carr and

Johanssen

(1995,

p.

51)

suggest Motorola's

success

with total

quality manage-

ment (TQM) and BPR is due, to a large measure, to their strong communication

plan.

The company

holds "town hall meetings" to review concerns, changes, and the overall state of the business with

their employees and managers hold informal communication sessions with their employees.

2

This list is adapted from one developed for reengineering as described in T. Davenport, "Don't

Forget the

Workers,"

Information

Week,

August 8,

1994,

p.

70.

DESIGNING A DECISION SUPPORT SYSTEM

Table 7.10. Tenets of Effective Communication

It is impossible to use too much communication.

Simplify your message, no matter how complex the issue.

Anticipate the issues and communicate your position early.

Don't underestimate the technical requirements of a communications project.

Involve all levels of management where appropriate.

Honesty is the best policy. Tell the truth.

Identify and know your audiences.

Source:

Adapted from D. K. Carr and H. J. Johansson,

Best

Practices

in

Reengineering,

New York: McGraw-Hill,

1995,

p.

55.

This material is reproduced with the permission of

the

McGraw-Hill Companies.

database mergers. For others, decision rules might be quite simple, coming quite close to

"gut feelings" or generalizations from past experiences. Decision makers may be concerned

about sharing these procedures, regardless of their reliability, for fear of looking silly or less

capable, and of fear they will need to learn new and harder methods of making decisions.

They may be unwilling to share accurate information about choice processes or information

and modeling needs. Of course effective communication is one approach to addressing this

resistance to change. Another is the implementation of a planned environment for change.

Finally, the third similarity is that good DSS design, like good BPR, takes place

incrementally over a period of

time.

BPR is best when it is limited to a process or a group of

processes at the outset. DSS design works best when a particular focus or type of analysis

is prototyped and built, then improved and expanded over

time.

Both require a multilayered

process that must be repeated over time. Further, managers need to become accustomed to

them before moving on to change another component of their organization.

DISCUSSION

When DSS have been designed well, they represent tools that add value to the process of

making selections among alternatives. Improvements in hardware and design tools release

designers to focus upon meeting the needs of the decision maker. Regrettably, there is no

process the use of which will assure the resulting system

is

a value-added product. However,

the use of prototypes to discuss specifications, an evolutionary strategy to development,

and good communication skills increase the chance of getting a useful and used system.

How to use Perusall notes